Grafana Beyla: Auto-Instrumentation Without Touching Code

javi
Dashboard de monitorización con gráficos y métricas en pantalla grande

Grafana Beyla solves a classic observability problem: instrumenting legacy or third-party apps. Instead of requiring code changes + SDK integration, Beyla observes syscalls via eBPF and generates OpenTelemetry traces automatically. For Go, Java, Python, Node, Rust — without touching the code.

What It Does

  • Auto-instrumentation of HTTP/gRPC requests.
  • Generates OTel spans with service name, method, status, latency.
  • Exports OTLP to any backend (Tempo, Jaeger, Datadog).
  • Multi-language: works with compiled (Go, Rust) and interpreted (Python, Node).
  • DNS tracking, SQL tracking (limited).

Architecture

[App]     [App]     [App]
   \        |        /
    \     (syscalls)
     \      |       /
    [Beyla eBPF agent]
          ↓ OTLP
    [OTel Collector / Grafana Tempo]

One Beyla per node (DaemonSet in K8s). Observes traffic of same-node apps.

Kubernetes Installation

helm repo add grafana https://grafana.github.io/helm-charts
helm install beyla grafana/beyla \
  --set env.BEYLA_AUTO_INSTRUMENT_TARGET=my-service \
  --set env.OTEL_EXPORTER_OTLP_ENDPOINT=http://tempo:4317

Or manual config:

service_name: my-api
log_level: info

discovery:
  services:
    - open_ports: 8080
    - exe_path: ".*/my-api"

otel_traces_export:
  endpoint: http://tempo:4317
  protocol: grpc

otel_metrics_export:
  endpoint: http://mimir:4317

Target apps by port, exe path, k8s labels.

Supported Languages

  • Go: excellent (native, deep visibility).
  • Rust: good.
  • C/C++: functional.
  • Java: basic HTTP (Java-agent auto-instrumentation richer).
  • Python: requests, aiohttp, Django.
  • Node.js: http, express, fetch.
  • .NET: basic.

For Go/Rust, almost like manual SDK. For others, complements SDK.

Metrics and Traces

Beyla generates:

Traces:

  • Span per HTTP/gRPC request.
  • Attributes: method, path, status, duration.
  • Context propagation (via W3C TraceContext headers).

Metrics:

  • RED metrics (rate, errors, duration).
  • Histogram buckets for latency.
  • Service graph metrics.

Standard OTLP output — any OTel-compatible backend.

Beyla vs SDK

Aspect Beyla (eBPF) Manual SDK
Code changes Zero Required
Granularity Call boundaries Custom business logic
Context propagation Header-based Explicit
Business metrics No Yes
Distributed tracing Limited for async Full
Performance overhead 1-3% 1-5%

Beyla: great first step, legacy apps, quick wins. SDK: essential for rich business-level observability.

Using both is common pattern: Beyla for broad coverage, SDK for critical apps with deep instrumentation.

Use Cases

Where Beyla shines:

  • Legacy apps you can’t modify.
  • 3rd-party apps (databases, caches) to observe ingress/egress.
  • Quick observability POC before investing in SDK.
  • Fill gaps in apps where SDK is imperfect.
  • Multi-language cluster with uniform observability without adapting each language.

Limitations

Honest:

  • Context propagation limited if app doesn’t forward trace headers.
  • Deep app spans invisible (only ingress/egress).
  • Business metrics impossible — Beyla sees only syscalls.
  • HTTPS encryption: Beyla doesn’t decrypt (sees only TLS metadata).
  • Performance overhead on I/O-heavy apps.
  • eBPF kernel requirements: 5.8+ recommended.

Grafana Stack Integration

Complete stack:

  1. Beyla on each node → OTLP.
  2. Grafana Alloy (optional) as collector.
  3. Grafana Tempo for traces.
  4. Grafana Mimir/Prometheus for metrics.
  5. Grafana for visualization.

Service Graph auto-generated from Beyla data.

Context Propagation

For complete distributed traces, apps must forward W3C TraceContext:

  • Go HTTP client: add OTel HTTP client middleware.
  • Python requests: opentelemetry-instrumentation-requests.
  • Envoy sidecar: automatically propagates.

Without propagation, each service has local traces but not unified cross-service.

Beyla vs Pixie

Pixie (CNCF sandbox) is more complete competitor:

  • Integrated visualization.
  • Query language (PxL).
  • Flame graphs.

Beyla is more focused:

  • Generate OTel data.
  • Lightweight.
  • Native Grafana-stack integration.

For Grafana-heavy stacks, Beyla. For Pixie-native, Pixie.

Real Overhead

Measured:

  • CPU: 0.5-2% per Beyla agent.
  • Memory: ~50-100MB.
  • Network: minimal (OTLP compressed).
  • Latency on apps: <1ms added.

Low enough for production.

Security

Requires:

  • Privileged container (eBPF).
  • HostPID to see processes.
  • HostNetwork for certain features.

Considerable security surface. Strict RBAC recommended.

Incremental Deployment

Adoption path:

  1. Beyla in staging observing some services.
  2. Validate overhead and data quality.
  3. Roll out cluster-wide.
  4. Compare with SDK in instrumented apps, identify gaps.
  5. Decide which apps keep both, which only Beyla.

Easy rolling back — no app changes.

Conclusion

Grafana Beyla is ideal tool to kickstart observability without long instrumentation project. For Go apps and legacy services, immediate value. For modern apps with proper SDK, Beyla complements but doesn’t replace. Beyla + OTel SDK combination covers observability spectrum with minimum effort. For teams on Grafana stack, natural inclusion. For Datadog/New Relic teams, Beyla OTLP output = portable.

Follow us on jacar.es for more on observability, eBPF, and Grafana stack.

Entradas relacionadas